前言：課表內容編輯、教室細項設定、所有教室狀態如何共同維護資料？

上一篇我們補齊了管理者功能的最後一塊拼圖，今天我們要退後一步，為這條龐大的「管理者功能線」進行整體的系統覆盤。

在先前的篇幅中，我們深入探討了「課表內容編輯」、「教室細項設定」與「所有教室狀態」背後的實作細節。為了避免陷入逐一攤開檔案的流水帳，本篇將採取 全景流程視角 －－從最前端的「登入功能」為起點，串連這三條支線的操作流程與職責邊界，帶大家看清整個後台是如何完整地維護所有教室資料。

三條管理者功能線

課表內容編輯：
LessonManageActivity + LessonManageViewModel修改某教室某時段是否有課，或刪除整筆教室資料。

教室細項設定：
ClassroomChooseManageActivity + ClassroomAdapter + ClassroomManageActivity選一間教室後修改 classroomType。

所有教室狀態：
AllClassroomsActivity + AllClassroomsAdapter + ClassroomScheduleDetailActivity總覽所有教室、可新增教室、點進去看有課時段。

管理者功能線流程

1. LoginActivity 與 ManagerActivity

LoginActivity
    ↓（登入成功）
isLoggedIn = true
    ↓
ManagerActivity
    ├─ 課表內容管理：LessonManageActivity
    │
    ├─ 教室細項設定：DetailChooseActivity
    │
    ├─所有教室狀態：AllClassroomsActivity
    │
    └─ 登出

• LoginActivity 是管理者入口，負責登入驗證。
• ManagerActivity 是後台選單，負責分流到三條管理者功能線，也處理登出。

2. 課表管理線

LessonManageActivity
        ↓ 使用者選大樓 / 樓層 / 教室 / 星期 / 時段 / 是否有課
LessonManageViewModel
        ↓ 根據 allSchedules 算 floors / classrooms
LessonManageActivity
        ↓ 按修改 / 刪除
LessonManageViewModel
        ↓ repository.update / delete
Repository → DAO → Room Database

• 課表內容編輯頁讓管理者選擇大樓、樓層、教室、星期、時段、是否有課，並修改該時段資料或刪除整間教室。這條線修改的是 mon1 ~ fri8 這些課表時段欄位，或刪除整筆 ClassroomSchedule。

3. 教室設定線

ClassroomChooseManageActivity
        ↓ 顯示所有教室名稱
ClassroomAdapter
        ↓ 點擊教室，putExtra("CLASSROOM_NAME", classroom)
ClassroomManageActivity
        ↓ SavedStateHandle 取得 CLASSROOM_NAME
        ↓ repository.getClassroomDetails(name)
        ↓ 顯示教室名稱 / 類型 / 是否可飲食
        ↓ 修改 classroomType
        ↓ repository.update()

• 教室詳細設定頁先讓管理者選一間教室，再進入真正設定頁修改教室類型。這條線修改的是 classroomType，例如 Normal、Computer、Lab。

4. 教室狀態線

AllClassroomsActivity
		  ↓ 取得所有 ClassroomSchedule
		  ↓ 轉成 ClassroomInfo
AllClassroomsAdapter
		  ↓ 顯示卡片
		  ↓ 點擊卡片，putExtra("CLASSROOM_NAME", classroom.name)
ClassroomScheduleDetailActivity
		  ↓ 查出完整 ClassroomSchedule
		  ↓ 只列出 == "X" 的有課時段

• 所有教室狀態頁顯示所有教室，也能新增教室，點進某一間後顯示完整有課時段。這條線主要讀取所有 / 單一 ClassroomSchedule，也能新增新的 ClassroomSchedule。新增時所有時段初始為 null，代表預設沒有課。

補充

共同資料核心：ClassroomSchedule

X 的不同使用情境

查詢空教室：不是 X → 可用
課表管理：是 → 寫 X；否 → 寫 null
課表詳細頁：是 X → 列出有課時段

X 的意義固定是「有課 / 被佔用」，但不同頁面使用角度不同：X 本身不變，變的是頁面目的。

這條管理者功能線所遇到的技術債

1. 資安防護不足

• 帳密寫死在程式碼裡（硬編碼）：帳號密碼直接寫在 App 裡，只要有人把 APK 反編譯，就能直接看到明文密碼，就像把鑰匙插在門上一樣不安全。

• 後台沒有檢查登入狀態：ManagerActivity 沒有做「身分驗證防護」。如果有人知道這支 Activity 的名稱，甚至可以繞過登入頁直接跳進管理後台。

2. 修改的資料可能會被覆蓋

• 重開 App 可能洗掉修改紀錄：如果系統每次啟動都重新讀取原始的 CSV 檔案，管理者在 App 裡辛苦「修改」或「刪除」的課表，很可能會被原始 CSV 檔直接覆蓋掉。

• 手動新增的教室沒有遠端備份：管理者新增的教室只存在手機本地的 Room 資料庫裡，一旦 App 清除資料或重裝，新增的教室就會直接消失。

3. 擴充彈性低、邏輯重複

• 大樓代碼寫死在程式裡：目前用 Regex("^(SF|ES)...") 規定教室一定要是 SF 或 ES 開頭。如果學校未來新建了別棟大樓，整套驗證與樓層推算就會直接失效，必須重寫程式碼發版。

• 「是否可飲食」是推導出來的：資料庫裡沒有「可否飲食」這個欄位，而是靠「只要是一般教室就當作可以飲食」來推導。如果未來出現「可以飲食的電腦教室」，這個邏輯就會破功。

• 中英文轉換重複分散各地：把 "Normal" 轉成 "一般教室" 的 when 判斷式，在好幾個 Activity 和 Adapter 裡都各寫了一遍。以後想改一個名詞，就得翻遍所有檔案一個個改，很容易改漏。

4. 元件管太多、畫面暴力刷新

• Adapter 越權處理跳頁：列表的 Adapter 本來應該只負責「把資料畫在畫面上」，但程式裡卻讓 Adapter 直接去執行 startActivity 跳頁，讓列表和特定頁面綁得太死，無法拿去別的地方重複使用。

• 暴力重刷列表（notifyDataSetChanged）：只要有一點點資料改變，就叫整個列表全部打掉重畫。雖然寫起來最快，但資料一多就容易卡頓，應該換成只更新變動項目的 DiffUtil。

• 檔案命名不一致：有的叫 ClassroomScheduleDetail，有的 Layout 卻叫 detail_setup 或 detail_choose，命名沒有統一規範，專案檔案一多就會找不到誰跟誰是一組的。

完整流程圖

                    LoginActivity
                          │
                          ▼
                   ManagerActivity
                          │
      ┌───────────────────┼───────────────────┐
      │                   │                   │
      ▼                   ▼                   ▼
  課表管理             教室設定             教室狀態
      │                   │                   │
      ▼                   ▼                   ▼
修改 / 刪除課表       修改教室類型        查看 / 新增教室
      │                   │                   │
      └───────────────────┼───────────────────┘
                          ▼
                Repository → DAO
                          │
                          ▼
                   Room Database

Hermes Agent 幫我檢查出的重點

RoomRush 的管理者功能從 MainActivity 的 Manage 入口進入 LoginActivity，登入成功後到 ManagerActivity。

ManagerActivity 是後台選單，會把管理者分到三條主要功能線：課表內容管理、教室細項設定、所有教室狀態。

• 課表管理線透過 LessonManageActivity 和 LessonManageViewModel 修改 ClassroomSchedule 的時段欄位或刪除整筆資料。
• 教室設定線透過 DetailChooseActivity、ClassroomAdapter、DetailSetupActivity 修改 classroomType 。
• 教室狀態線透過 AllClassroomsActivity、AllClassroomsAdapter、AllClassroomsSchedule 顯示所有教室與單一教室有課時段，也能新增新的 ClassroomSchedule。

三條線共同圍繞 ClassroomSchedule，只是修改或讀取的欄位不同。

小結

整理完管理者功能後，我發現 RoomRush 的後台其實可以分成三條很清楚的線。第一條是課表管理，管理者可以選擇大樓、樓層、教室、星期與時段，決定該時段是否有課。第二條是教室設定，管理者先選擇教室，再修改教室類型。第三條是教室狀態，管理者可以看到所有教室的基本資訊，點進去後查看某間教室完整的有課時段，也可以新增教室。

這三條線雖然畫面不同，但資料核心其實都是 ClassroomSchedule。課表管理修改的是 mon1 到 fri8 這些時段欄位；教室設定修改的是 classroomType；教室狀態則讀取教室名稱、類型與時段資料，也能新增整筆教室資料。這讓我更清楚看懂 Entity 在專案裡不是孤立存在，而是被多個功能共同使用。

管理者功能也暴露出許多技術債。例如管理者帳密硬編碼、登入狀態檢查不足、CSV 重新匯入可能覆蓋管理者修改、大樓格式硬編碼、是否可飲食不是獨立欄位、教室類型轉換邏輯重複、Adapter 直接處理跳頁，以及多個檔案命名不一致。

一句話總結：

管理者功能 = 登入後進入後台，分成課表管理、教室詳細設定、瀏覽教室狀態三條線，三條線都圍繞 ClassroomSchedule 讀取或修改資料。

下一篇預告：不是每個檔案都要深讀：我如何判斷主流程與支援檔案？

整個管理者功能線釐清完之後，整份總覽都很清楚了。下一篇文章會比較特別，我們要聊 專案中的歷史檔案。

在專案因分工或是快速演進的過程中，難免會殘留一些與現有邏輯高度重疊、卻未被主流程正式使用的 ViewModel 與 Factory。下一篇我們將帶大家拆解這些檔案的來龍去脈：分享我如何抽絲剝繭理清它們的定位，並在維護過程中辨別哪些是「專案核心」、哪些是「待清理的過渡代碼」。